-
Notifications
You must be signed in to change notification settings - Fork 485
Add in progress note to internal_certificate_spec #34364
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| /// The cert-manager Issuer or ClusterIssuer to use for database internal communication. | ||
| /// The `issuerRef` field is required. | ||
| /// This currently is only used for environmentd, but will eventually support clusterd. | ||
| // Implementation in progress: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it makes sense to have the "implementation in progress" notes as a normal (non-doc) comment, but can we also add a big "do not use" warning as a doc comment here as well, so it shows up in our generated docs?
e1a3252 to
21777ac
Compare
| /// The cert-manager Issuer or ClusterIssuer to use for database internal communication. | ||
| /// The `issuerRef` field is required. | ||
| /// This currently is only used for environmentd, but will eventually support clusterd. | ||
| /// Implementation in progress: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think we need in progress notes in our public docs? can we just say "not yet implemented" in the public doc comment like console_external_certificate_spec does, and leave the progress notes as a non-doc comment?
21777ac to
0d45755
Compare
0d45755 to
d3bd887
Compare
| "name": "internalCertificateSpec", | ||
| "type": "MaterializeCertSpec", | ||
| "description": "The cert-manager Issuer or ClusterIssuer to use for database internal communication.\nThe `issuerRef` field is required.\nThis currently is only used for environmentd, but will eventually support clusterd.", | ||
| "description": "The cert-manager Issuer or ClusterIssuer to use for database internal communication.\nThe `issuerRef` field is required.\nThis currently is only used for environmentd, but will eventually support clusterd.\nNot yet implemented.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh ... that "Not yet implemented" -- Is it referring to the clusterd part? Because it's in a standalone sentence ... it makes it sound like the whole thing is not yet implemented. Kind of like, if we had added a Deprecated afterwards ... it'd be more for the whole thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ... actually, reading the description... exactly, what is not implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using internalCertificateSpec will not do what people expect, because the implementation of that feature is only partially complete - customers should not be using it at all.
Motivation
Currently we don't validate the cert on the balancer side. It'll still generated an used to encrypt but since there's no validation it's susceptible to MIM.
Tips for reviewer
Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way), then it is tagged with aT-protolabel.